Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0049/404.txt

Text File | 1997-04-16 | 18KB | 441 lines

Info-Atari16 Digest   Tuesday, August 22, 1989   Volume 89 : Issue 404

This weeks Editor: Bill Westfield

Today's Topics:

                           Re: Archive bit
              ICD host adapter problems with SONY drive
                      Re: Multitasking on the ST
                       New Atari 68030 Machines
                       Re: Screen flicker, top
                           st1040s in Pgh?
                            Mac emulation
                      Re: Multitasking on the ST
                            Re: user base
                              ST market
                            cartridge port

----------------------------------------------------------------------

Date: 14 Aug 89 23:21:11 GMT
From: imagen!atari![e-mail]  (John Townsend)
Subject: Re: Archive bit
To: [e-mail]

in article <[e-mail]>, [e-mail] (Mark
 Powell) says:
>
>
>   Bit 5 of a file mode is the archive bit. This is to do with backing up
 files.
> When a file is backed up it's archive bit is set. When it is next written to
> the bit is cleared. From this senario the disk back up program can tell
 whether
> a file has been modified since the last back up and if so back up the file
> otherwise leave it. This enables an incremental backup to be performed i.e.
> back up your hard disk totally every month, and backup just the files that
 have
> changed every week. Unfortunatley this procedure doesn't work on the old TOSes
> (or so I'm informed) TOS 1.4 is said to fix this.
>   I have seen plenty of files on my disks with this bit set. You may be
 running
> a different TOS from me though. I've got a UK TOS 1.0 dated 20/11/85
> i.e. 20th November for you in the US who don't put the date in ascending or
> descending order of significance (make your minds up!)
>

You have it backwards. In TOS 1.4, the bit is set when a file is created or
modified. The backup program should clear it after backing up the file.


-- John Townsend
   Atari Corp.

------------------------------

Date:     Tue, 15 Aug 89 09:22 GMT
From:     [e-mail]
Subject:  ICD host adapter problems with SONY drive
To:       [e-mail]
X-Original-To:  [e-mail], IKT7

Hi folks

We are seeking help on connecting a SONY SRD2040Z harddisk via a ICD
host adapter to an ATARI ST as we are experiencing some problems.

First of all we would like to mention that we connected this drive to a
MAC SE. The SONY hard disk could be formatted and installed without any
problem. This gives us the impression that not the drive is faulty as
it behaved like a SCSI drive should. It may be of some interest to know
that APPLE has a contract with SONY for a large amount of these drives.


Observing the signals on the SCSI bus with a logic analyzer we have found
out that the request/acknowledge handshaking doesn't work:

- The first ACK going true coincides with the first REQ while no valid data
  is on the bus. From then on the handshaking doesn't work so that the
  whole command sequence is not closed in right manner.

- We have tried all available drivers including the SYQUEST 555 (similar
  SCSI controller) to format our drive. None of them complies to our
  SONY drive.

Does anybody on the net have any advice on what else to try? Any hint
will be appreciated.

Thanks a lot in advance for your help!


Hansruedi Andrist

------------------------------

Date: 15 Aug 89 04:18:08 GMT
From: cbmvax![e-mail]  (Joe O'Hara - QA)
Subject: Re: Multitasking on the ST
To: [e-mail]

In article <[e-mail]> [e-mail] (Daniel B. Suthers)
 writes:
>After reading this a question popped into my head.  If you are downloading in
>the back ground (it seems the most popular multi-task task) and running a
>action game in the foreground,  do you set the download process to the
>highest priority to avoid losing data or do you just put up with longer
>download times and connect times so your joy-stick will be responsive?

Believe it or not, the answer is neither. The actual I/O is processed by
device drivers, in these examples the serial device and the gameport
device. The drivers have higher-than-standard priorities. In the download
situation, received characters are stored in a buffer until the application
program gains control and "reads" them (burst them into the program). The
joy-stick action results in events which are passed to the game program as
messages. Consequently, the game program could be given higher priority if
you wished without a noticeable degradation of the teleprocessing task. The
serial device buffer can range from 512 - 16,000 bytes (user controlled).
--
========================================================================
  Joe O'Hara                ||  Comments represent my own opinions,
  Commodore Electronics Ltd ||  not my employers. Any similarity to
  Software QA               ||  to any other opinions, living or dead,
                            ||  is purely coincidental.

------------------------------

Date: 14 Aug 89 18:13:39 GMT
From: astroatc!nicmad!madnix![e-mail]  (Curt Chambers)
Subject: New Atari 68030 Machines
To: [e-mail]

Just caught a news bit in InfoWorld concerning "new" Atari
68030 machines w/VME slots that will run Atari Unix Sys. V.

Is this true?  Cringely's article went on to say that they would
be released on the 25th of August.

Anybody know anything else?

Curt Chambers

------------------------------

Date: 15 Aug 89 08:48:57 GMT
From: mcvax!hp4nl!phigate!philmds![e-mail]  (Leo de Wit)
Subject: Re: Screen flicker, top
To: [e-mail]

In article <[e-mail]> [e-mail] (Bob Currier -
 DCAC Network Comm. Specialist) writes:
|Greetings,
|
|This weekend, while noodling around with animation, I came across a
|most puzzling phenomena.  My graphics displayed fine while on the
|lower part of the screen (I am using a monochrome 1040), but when
|my little critters got about 30 or 40 pixels from the top they
|started to get a bad case of the flickers.  I was using Vsync() to
|control flicker, and it seemed to work well, except for this
|twilight zone.
|
|I pulled my hair out for a couple of hours on this one, dug thru all
|my books, and finally, at about 1 a.m., in the premier issue of START,
|found a comment in an article about al graphics that went like this:
|
|"...vsync, but you will still see flicker near the top of the screen.  This
|is a problem that can only be dealt with by very complex multiple screen
|flipping techniques..."
|
|So, does anyone know of this problem?  What causes it? And, Virginia, how
|can I eliminate it?

My name is not Virginia, Bob, but I still think I can make some sensible
remarks about this one.

Flicker is caused by updating the physical screen, that is: writing to
the physical screen in some way. Most often one erases part of the
screen, then draws on the erased part; at the same time this part of
the screen is being read by the video stuff. Most animations use a
separate screen to draw in, then as the picture is complete, swap the
screens. All GEMDOS, (X)BIOS and GEM functions that deal with graphics
(including characters) are being drawn on the logical screen (a chunk
of 30000 bytes of memory pointed to by a system vector, 0x44e if my
memory is OK 8-). The physical screen location is determined in two I/O
addresses (it always starts on a 256 byte boundary).  For reading the
screen 3 I/O addresses are being used; they correspond to registers in
the shifter (an ST custom chip for the video stuff). After each VBL
these addresses are reinitialized from the two 'physical screen start'
I/O addresses (this is also the reason that, though you could alter the
physical screen start between VBL's (the XBIOS function Setscreen()
does this), it can only take effect at the moment of the next VBL (the
3 I/O addresses for reading the screen are read-only).

The Vsync() is not totally unuseful: it synchronizes your software with
the VBL, that is, you know that after a Vsync() statement the shifter
reads at the top of the screen (so at that moment avoid updates there).
You could do updates to the lower part of the screen, or use a timing
loop so you know the shifter already has had the upper part.
Alternatively you could read the 3 I/O addresses (in supervisor mode,
of course) to determine where the shifter is currently reading; in this
case you don't need the Vsync(), which really can speed things up (I
know, I did this myself).

The most commonly used technique is to use two separate screens, one as
the physical screen, one as the logical (as mentioned above), draw your
stuff on the logical one, then use Setscreen to swap the screens. Now
you must do a Vsync() before any new updates of the (new) logical
screen, because remember until VBL it is still the old physical screen,
which is being read by the shifter.  This technique is guaranteed to be
flicker-free, and, as opposed to what was possibly mentioned in START,
is not difficult at all.

A third technique is a somewhat more complicated variant of the second one.
Its main idea is to use several screens (more than two) to avoid using
Vsync(), thus gaining in speed. You use the screens alternatively:

screen1 physical, screen2 logical
screen2 physical, screen3 logical
etc.

screenn physical, screen1 logical
screen1 physical, screen2 logical
etc.

The number of screens to use depends on the speed with which you can
draw a new image on the logical screen. Since a physical screen remains
fixed for at least one VBL period, doing the cycle of n screens must
take at least one VBL. Since it doesn't make sense to swap screens a
lot during a VBL period (only the last one takes effect) and it DOES
take some time in general to redraw your screen, a useful number of
screens is 3.

Hope this helps - if you need the exact location of the I/O addresses
I can look it up for you.

    Leo.

------------------------------

Date: 15 Aug 89 13:57:54 GMT
From: [e-mail]  (Alan Kennedy)
Subject: st1040s in Pgh?
To: [e-mail]

Does anyone know how to buy a 1040 in
Pittsburgh?  I've been phoning one shop
At Your Service, but they never answer
their phone.  Is the best thing to do
to order by mail from NY?

------------------------------

Date: 14 Aug 89 09:43:16 GMT
From: mcvax!cernvax!unizh![e-mail]  (draxler)
Subject: Mac emulation
To: [e-mail]

Hi there,

I am new to the net, so please excuse my question if it has been answered
already...

Are there any legal problems in using a Macintosh emulator (such as Aladin
or others)? What I need is a quoteable source, no rumours! Maybe the legal
situation in different countries is different.. So what is it like in
Germany and in Switzerland?

If there are no such problems, which emulator is best? Which programs are
known to work, which programs won't work? How do I get my Mac data and
applications to my ST? Can I drive my Laser printer from the Mac software?
Can I read and write to Mac disks? Can I use my Atari Harddisk?

Yes, load'sa questions...

Reply by e-mail to Christoph Draxler: [e-mail]

------------------------------

Date: 15 Aug 89 10:58:43 GMT
From: mcvax!hp4nl!phigate!philmds![e-mail]  (Leo de Wit)
Subject: Re: Multitasking on the ST
To: [e-mail]

In article <[e-mail]> [e-mail] (John
 Lindwall) writes:
|In article <[e-mail]> [e-mail] (Leo de Wit) writes:
|[]
|
|This point is well taken, but does not negate the point that process protection
|is desirable (in my mind).

I would be the last one to deny that; what I meant was that a
non-multitasking machine like the ST can benefit from process
protection too.

|>                                                             My point
|>is, that a MMU is a probably undispensable ingredient IN AN OTHERWISE
|>EXCELLENT SYSTEM.  That safe system (which undoubtedly will have a
|>notion of privileges, users) is what you should start with in the first
|>place.
|>
|
|An MMU can protect pages of memory that the system considers special.  The
|system vectors could be marked as un-writable by user level processes. An
|attempt to modify the protected pages could be trapped and prevented.

Any usable system will have to have a way to install (re-install) system
vectors, switch to supervisor mode etc. In the current TOS each user program
can do that. What I meant was that the system should have a notion of
users with special privileges (root) so that one cannot inadvertently
switch to kernel mode and do strange things. If you want to do something
special, OK become root and then do your stuff (very careful), then go
back being a normal user. This should be a hard fact in the system; it
could prevent a lot of viruses.

|>B.T.W. what do you do when a thunderstorm is coming up, but your
|>raytracer has yet to finish its last hour of calculations? Use a TMU :-) ?
|>
|
|Well, here in Sunny California (tm) we don't get many of those! :) :) :)

Here in Rainy Holland (B.V.) we usually get them after a few sunny days
(I shouldn't complain however - we had the best summer in years).

|>|I'm all for system robustness for ANY system.  My point is that when you
|>|introduce multitasking, memory protection is more important due to the
|>|potential to disrupt other processes.
|>
|>I heard this one before and I still won't believe it, unless a proper
|>argument is given.
|>
|
|So I assume (if you were using a multi-tasking system) that you would prefer
|NOT to have process protection?  I do not see the logic in this.

No, what I meant was that I would prefer to have memory protection in
both cases. I don't see a reason why it should be more important in the
multitasking case. You can have lots of vulnerable processes in the
other case as well.

|Yes, VM is nice.  In my day-to-day Amiga experience I do not run out of memory
|much.  I DO experience agonizing crashes which kill all my processes.  From
|this experience I developed the priority of process protection being more
|important.  If VM were available, I'm sure I would enjoy it and make use of it.

>From what I hear in this group, a lot of people DO run out of memory -
even the ones with > 1 M memory. Accessories, TSR's, RAMdisks, disk caches
all grab a (not to be ignored) constant part of your memory. Now try and run
something like gcc (a known memory hog). Lots of people expanded their memory
already. But IMHO the most important use for VM is not protection, not paging
in additional memory when needed, but ... the processes being position-
independent! Try to implement the UNIX fork() call, you know what I mean
(also relocation becomes unnecessary, but that is a minor issue).

|
|Thank you for this enjoyable discussion.  I hope it can continue on the
|amiable and informative level that has been maintained all along.  Looking
|forward to your reply.

Thank you too, me too, me too (in that order). Cheers,

                 Leo.

P.S. One noticeable difference between ordinary conversations and
Usenet discussions is that the former resembles multitasking, the
latter something like coroutines 8-).

------------------------------

Date: 15 Aug 89 16:02:44 GMT
From: [e-mail]  (Mark O'Bryan)
Subject: Re: user base
To: [e-mail]

In article <[e-mail]>, [e-mail] ( SunVis) writes:
>
>   Does anyone have an idea how many ST's & MEGA's have been sold in N.A.
>  and Europe as well as Asia ect.

According to Sam Tramiel in a recent issue of STart magazine, there are
almost 1.5 million worldwide, and almost 200,000 in the U.S.  I don't
know how close "almost" means, but this is what he reported.

Beyond just the raw numbers, however, you'll want to consider what seg-
ment of the potential market is going to be interested in your product.
This is almost never close to 100%, usually much, much less.

--
Mark T. O'Bryan                 Internet:  [e-mail]
Western Michigan University
Kalamazoo, MI  49008

------------------------------

Date: 15 Aug 89 16:00:13 GMT
From: blake![e-mail]  (Moja Fritzah)
Subject: ST market
To: [e-mail]

I ran out last night to pick up the infoworld issue
describing the TT.

I stood back a bit from the large array of computer journals,
reading the covers of most.

The Atari journals spotlighted "Bingo; Calorie Counter; Games and
Entertainment..."

ATARI can't be blamed entirely for creating the "game machine"
sobriquet.

------------------------------

Date: 15 Aug 89 15:50:39 GMT
From: blake![e-mail]  (Moja Fritzah)
Subject: cartridge port
To: [e-mail]

NOTATOR requires a dongle in the cartridge port for copy protection.
I would like to purchase the GCR... as well as a few other products
requiring use of the cartridge port.

I know this subject has been of issue for as long as the machine
has been in existence.  But what is the latest development on the
expansion of the port?

C-Lab, the makers of NOTATOR, have come up with a product
that allows 3 dongles to hang off the cartridge port.
They are asking $349.00 !!!

I think this is perfectly unreasonable.  Anybody disagree?

-kevin
[e-mail]

------------------------------

End of Info-Atari16 Digest
**************************
-------

ə